2024-0519-1622 Valve's Design Process for Creating Half-Life 2
- type of notes
#Archived
#LiteratureNotes
Slip-box
To be fleeting notes
Fleeting
To be literature notes (Understanding)
L-Origin
L-My Words
- Fun
- I know it when I see it
- 但 valve 相信 fun 是可以通过工程学方法来实现的
- 目标，限制
- 提出达成的方法
- 做实验来测试
- 评估实验结果
- 评估想法
- 评估目标
- 反复
- 必要的 ingredient
- 正确的态度——准备好犯错
- 清晰定义、可被评估的目标
- 可被沟通的目标（具体，而不是泛化的目标）
- 团队需要达成共识
- 精心设计过的测试以避免实验者偏差
- 定义目标
- 从玩家（消费者）的角度来思考
- 关心游戏质量，而不是个人贡献
- 使用消费者视角来过滤不必要的目标
- 好的玩家体验 = 成功
- Engineering Game Design
- 目标是好玩的游戏
- 你的想法就是你的设计
- Playtest 是你的实验
- 基于 playtest 的结果来评估你的设计
- 反复进行
- Playtest 到底意味着什么
- 不是 QA
- 这是关于寻找 bug 的
- 不是平衡
- 平衡是确保没有明显的最优选择的
- 不是 Focus Testing
- 这是关于目标用户的市场研究的
- 意味着 fun
- 要测试的是玩家在游玩你的游戏的时候是否觉得有趣
- 不是 QA
- Running a good playtest
- 玩家是否能获得你所设计的体验（机制测试）
- 你所设计的体验是好的体验吗
- 了解影响玩家体验的方方面面
- Running a good playtest
- 让相关的人都来观看
- 简化评估流程
- 大家很清楚期望是什么，也很容易看出哪里出了问题
- 便于设置优先级
- 观看时很容易看出哪些问题更加严重
- 让大家更有动力
- 看到玩家晕头转向不知道怎么办的时候，设计师们会很痛苦，也就会很有动力让其变得更好
- 简化评估流程
- 为玩家安排类似于家里的环境 - unbiased test
- 没有提示
- 在测试期间不要回答问题
- 不要提供额外的奖励（不要在他们表现好的时候摇旗呐喊！保持安静！）
- 设置额外的屏幕让所有相关的设计师们（一般是六七个人）观看
- 随机找外部人员
- 业内人经过训练，很可能无法暴露问题
- 让相关的人都来观看
- Questioning playtesters
- 不要太依赖于问题，答案很可能不那么真实
- 你的问题可能会让他们想起本来错过了的东西（但其实他们错过这件事本身更有价值）
- 不要问具有引导性的问题
- 可以针对某些特定元素发问，会很有用
- 叙事内容 narrative content
- game systems - tutorial
- 玩家是否真的学会了你想要教的东西，还是只是碰巧一直在用（但其实根本不知道那是啥）
- Design iteration
- 很多时候发生在开发后期
- 那时只能专注于解决严重的设计问题
- 应该尽早开始以发挥其最大的价值
- 越往后， Playtest 价值越低
- 那时可能没办法对设计做太大的更改了
- Playtesting as production
- 为了减少迭代成本，早期测试版本应该只包含最基本的架构（玩家可以站立的部分+防止玩家掉落的保护）
- 这是最终版本
- Small increments
- 只要有东西可以让你知道玩家可能会有不同的反馈就可以测试
- 1-2 周作为增量周期
- 太短了可能来不及做更改
- 太长了可能会成为沉没成本
- 或者根本不清楚改动是否真的有帮助
- 不要让理论上存在的困难影响 Playtest 的进行
- 可能这在游玩时不会成为麻烦
- 如果真的是麻烦，playtest 可以帮助你看清优先级
- Playtest 可能会帮助你想出更好的解决方案
- 不用担心视觉影响
- 美术迭代的风险比设计迭代要低一些
- 并且在早期迭代美术可能更贵
- 其他好处
- 可以帮助你学习
- 事情并不如你期望般发生
- 玩家在压力下啥也学不了
- 更容易辨别你的改动到底有好处还是帮了倒忙
- 是很好的帮助减少设计争论的办法
- 可以利用 Playtest 的结果来驱动其他模块的生产
- 可以帮助你学习
- Playtesting as production
- Playtest 中发现的问题，可能需要通过迭代的方式来解决（可能没办法一次就解决好）
- 没有必要过度解决问题，挑简单快速的方案（即使它可能不一定能解决，但依然有可能这就够了）
- 以正确的顺序进行测试
- 对于新的元素，可能会先让测试者在一个迷你地图中学习一下用法，之后再开始正式测试
- 寻找趋势
- 不要过度解决
- 测试是在用小样本来寻找大的趋势
- 单次结果的好坏不应该具有决定性影响
- 如果好几次都看到玩家有相同的表现，这可能才是真实情况
- 不要犹豫不决
- 有些问题没有绝对正确的解决方案
- 不要过度解决
- 将一个事情推到 shippable 品质再看下一个
- 这样能够更好地清楚到底是哪部分出了问题
- 如果游戏中充满了半成品的部分，那可能无法进行归因
- 这样能够更好地清楚到底是哪部分出了问题
- Playtest 中发现的问题，可能需要通过迭代的方式来解决（可能没办法一次就解决好）
这和基于整体完成度的开发思路完全不同
- Time x quality x scope
- 通常而言， TIME X SCOPE 是决定因素，但这样就会导致 quality 下降
- 但如果采用 valve 的方法——将一个特性打磨到几乎可以发售的程度再做下一个，这样 quality 就可以得到保证，最坏的结果是 scope 受影响，即游戏太短，但品质很高
- 由此会让你想要引入的每一个设计都会有时间风险
- 因为你并不知道需要花多久才能让其变得有趣或达到可发售的质量
- 所以这样一般来说在时间到了的时候，你所引入的一般都是比较重要的，并且几近完成的元素
- 之后所投入的每一份力都可以朝着强化已经成功的元素的方向前进
- 这样同时也能提高整个游戏的质量
- 可以利用完成一个特性的资源作为完成整个项目所需的资源的参考
-
Playtesting as production in larger projects
- 创建多个独立的设计小组(5-6 个人)
- 让他们独立负责一小块内容
- 创建一个让每个团队可以在其中工作的沙盒（从而不破坏其他团队的工作）
- 他们要决策的事情
- Level design
- Minute to minute gameplay
- ...
- 他们要决策的事情
- 创建全局决策的处理流程
- 故事
- 全局机制
- 美术
- 一致性 consistency
- 品质
- 创建多个独立的设计小组(5-6 个人)
-
Process #1 - establish initial constraints
- 建立初始限制
- 在 preproduction 阶段建立最初的产品决策
- 建立玩法原型地图来解释它们如何工作
- 一些东西会被作为限制
- 另一些会被当做建议
- 也有一些重要元素是在后面的阶段才开发的
- 建立初始限制
-
Process #2 - promote design economy
- 鼓励用新方式来利用已有元素
- 这可以建立全局限制和质量标准
- 因为用的是相同元素
- 这个元素也会被不断打磨
- 以团队规模的 Playtest 来给其他设计团队展示元素
- 成功的元素在游戏中总是会被不断使用
-
Process #3 - establish strike teams
- 来解决跨团队问题
- 有一些 strike team 在整个项目期间都存在
- 比如 weapons cabal
- 很多只是短暂存在
- 比如一个团队想使用另一个团队的元素（可能为了避免元素的重复使用带来的重复体验）
- 经过良好测试的地图中的决策会被视为 constraints
- 比如已经测试过一个 NPC 的行为模式，另外一个 team 就不能再对其行为进行更改
- 有时候特殊情况也需要特殊处理，比如有一个后期 BOSS 被放到了开始阶段，但这样会让玩家感到很难
- 这样的情况下，最终的解决方案是为这个 BOSS 设置了一个简单版本（更少血量，更少伤害）
- 中间有很长时间玩家不会再见到它，所以在最终再次见到它的时候，也不会觉得他变难了而导致前后不一致（因为最开始的时候虽然是简单版本，但那时玩家熟练度稍低，所以难度上其实也是难的）
-
Process #4 - the Overwatch Cabal
- 在 alpha 阶段评估全局的产品品质
- 和所有团队沟通反馈结果（high - address/ low - not good）
- 从公司层面的 Playtest 给出建议和反馈
- 包含每个设计团队的一名设计师和美术/声音/动画/叙事团队的成员
- 设计团队需要负责来落实这些反馈
- 每个团队会单独决定是否要砍掉或做出改变
- 所有改变都会在 alpha 阶段（会持续四个月）进行
-
Alpha
- 在 alpha 阶段可以进行的改动
- 不能引入非常重要的新元素
- 把最严重的问题砍掉
- 如有必要，利用已有元素来提高元素密度
- 有一些东西直到最后完成前都没办法评估
- Pacing
- 难度曲线
- Variety
- 章节之间的不协调问题
- 在 alpha 阶段可以进行的改动
-
结论
- 游戏设计中可以运用工程学方法
- 让生产团队引导设计
- 使用 Playtest 来指导生产
- 如果运用合适的方法，大团队也能运用这样的方法
- 一但游戏全程可玩后，允许对游戏做一次从头到尾的最终迭代
-
QA
- 三个月开发周期
- 两周出可玩版本
- 两个月 alpha
- 迭代开发
- 拿原来的引擎+几个新 feature
- 从头开始迭代开发，最开始关注最重要的
- Preproduction 占了一半
- 如何维持 aesthetics - 氛围 atmosphere
- 即使团队不一样了
- Half-Life 2 是并行开发
- 美术资源是共享的
- 创建 style guide
- 美术资源是共享的
- Overwatch cabal 大概十个人
- 不是为了解决设计问题而只是提出问题和反馈
- 单次结果的好坏不应该具有决定性影响，需要观察趋势
- 但做得多了就会有直觉，看的时候就知道了
- 组织架构
- Project lead - as critics
- Art lead
- Narrative lead
- Sound
- Leads for design teams
- 大多决策都是合作决定的
- 美术和 narrative team 会和 design team 决定故事和基调，设计团队也有对应的目标 - 比如教学/引导
- Leads 不代表他有决策权，只是需要监管时间
- 一章节大概 100 个 playtester
- 提前找好，有需要就联系
- 类似敏捷开发
- 一次用一个，在全过程都用上
- 如何决定一个 feature 是失败的还是只是需要更多教程
- 基于一些原则
- 比如危急时刻无法进行教程
- 或是太耗费
- 根本想不到怎么好玩
- 如果有可以尝试的机会就尝试
- 基于一些原则
- 怎么测试后期内容
- 先让他们玩测试地图，知道有些什么东西
- 然后让他们玩一玩前面的可能碰到的内容，熟悉一下玩法
- 同时也会记录玩家已经玩过的部分，可能会在不同时间点找同一个玩家，这样他也相当于从头玩到尾了
- 保密
- 还是签了保密协议
- 但要让玩家关心你的游戏，如果他们关心，他们开心地发布相关内容，你可能就是成功的
- 如果确实有需要处理的情况，可能也可以邮件联系他们，粉丝们其实大多情况下也并不想让你们受到伤害
- 故事
- 最开始有故事版知道有哪些关键事件
- 故事也需要具有可调整性
- Trends
- 有时候不是真的数据
- 而是看了好多次的感觉 太明显
L-Zotero citation key
\cite{torlessbardamuValveDesignProcess2021}
To be permanent notes (Complete Ideas)
P-Self Explained Sentences
P-Connection
- Parent
- Caused by::
- - Driven by::
- - Cite from::
-
- Caused by::
- Child
- Excalidraw::
- - Is source of::
- - Including::
- - Have Example::
- - Contributes to::
-
- Excalidraw::
- Friend
- Left
- Achieved with::
- - Affected by::
- - Supported by::
- - Enhanced by::
- - related::
-
- Achieved with::
- Right
- against::
- - Opposites::
-
- against::
- Left